Telegram Group & Telegram Channel
Теперь немного подушним. За свою карьеру я-таки заметил одну вещь, от которой у меня пригорает. Многие разрабы не умеют в инкапсуляцию, от чего кишки классов и модулей часто вываливаются наружу.

Рассмотрим на примере. Представим что у нас есть вот такой класс:


class Disease {
var confirmed: Confirmed
}

enum class Confirmed {
YES, NO, NOT_SPECIFIED
}


Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
// какие-то проверки
this.confirmed = c
}


У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

Пример примитивный, но объём кучи навоза уже можно прикинуть. И многие разработчики не думают, как грамотнее инкапсулироваться, вываливают всё наружу, а потом жалуются, что у них всё слиплось.

Правильнее сделать примерно так:

fun confirm(){
// какие-то проверки
this.confirmed = Confirmed.YES
}

fun decline(){
// какие-то проверки
this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES


Методов больше, но зато внешний клиент знает меньше про устройство модуля, мы легко можем найти все вызовы без угадайки. К тому же светить Enum может оказаться совсем необязательным, ибо с точки зрения предметки нас интересует только факт подтвержденности диагноза, а что там внутри за статусы — вообще пофигу.

Но это ладно, когда мы знаем какой параметр передать, — это самый легкий случай. Иногда нужно знать последовательность вызовов или даже тайминг. Вообще, степень такой связности обозвали даже специальным словом Connascence.

Поэтому, когда вы пишете модуль, подумайте над следующим:
- Что вы можете скрыть и не показывать?
- Какие изменения внутри вашего модуля могут затронуть клиента?
Вы удивитесь, насколько проще клиенту будет работать с вашим модулем.



tg-me.com/stringconcat/226
Create:
Last Update:

Теперь немного подушним. За свою карьеру я-таки заметил одну вещь, от которой у меня пригорает. Многие разрабы не умеют в инкапсуляцию, от чего кишки классов и модулей часто вываливаются наружу.

Рассмотрим на примере. Представим что у нас есть вот такой класс:


class Disease {
var confirmed: Confirmed
}

enum class Confirmed {
YES, NO, NOT_SPECIFIED
}


Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
// какие-то проверки
this.confirmed = c
}


У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

Пример примитивный, но объём кучи навоза уже можно прикинуть. И многие разработчики не думают, как грамотнее инкапсулироваться, вываливают всё наружу, а потом жалуются, что у них всё слиплось.

Правильнее сделать примерно так:

fun confirm(){
// какие-то проверки
this.confirmed = Confirmed.YES
}

fun decline(){
// какие-то проверки
this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES


Методов больше, но зато внешний клиент знает меньше про устройство модуля, мы легко можем найти все вызовы без угадайки. К тому же светить Enum может оказаться совсем необязательным, ибо с точки зрения предметки нас интересует только факт подтвержденности диагноза, а что там внутри за статусы — вообще пофигу.

Но это ладно, когда мы знаем какой параметр передать, — это самый легкий случай. Иногда нужно знать последовательность вызовов или даже тайминг. Вообще, степень такой связности обозвали даже специальным словом Connascence.

Поэтому, когда вы пишете модуль, подумайте над следующим:
- Что вы можете скрыть и не показывать?
- Какие изменения внутри вашего модуля могут затронуть клиента?
Вы удивитесь, насколько проще клиенту будет работать с вашим модулем.

BY StringConcat - разработка без боли и сожалений


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/stringconcat/226

View MORE
Open in Telegram


StringConcat разработка без боли и сожалений Telegram | DID YOU KNOW?

Date: |

Telegram Auto-Delete Messages in Any Chat

Some messages aren’t supposed to last forever. There are some Telegram groups and conversations where it’s best if messages are automatically deleted in a day or a week. Here’s how to auto-delete messages in any Telegram chat. You can enable the auto-delete feature on a per-chat basis. It works for both one-on-one conversations and group chats. Previously, you needed to use the Secret Chat feature to automatically delete messages after a set time. At the time of writing, you can choose to automatically delete messages after a day or a week. Telegram starts the timer once they are sent, not after they are read. This won’t affect the messages that were sent before enabling the feature.

Mr. Durov launched Telegram in late 2013 with his brother, Nikolai, just months before he was pushed out of VK, the Russian social-media platform he founded. Mr. Durov pitched his new app—funded with the proceeds from the VK sale—less as a business than as a way for people to send messages while avoiding government surveillance and censorship.

StringConcat разработка без боли и сожалений from ua


Telegram StringConcat - разработка без боли и сожалений
FROM USA